home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-hares-idrp-04.txt
< prev
next >
Wrap
Text File
|
1993-03-21
|
46KB
|
1,365 lines
- 1 -
Network Working Group Susan Hares
INTERNET DRAFT NSFNET/MERIT
Version 4 March 1993
IDRP for IP
Status of this memo
This memo specifies the adaptation of the ISO Inter-Domain Routing
Protocol ([1]) that enables it to be used as an Inter-Autonomous
System routing protocol in the TCP/IP Internet. IDRP with this
adaptation will be called "IDRP for IP" in this document. Dual
IDRP, that is, a single instance of IDRP that can simultaneously
support Inter-Domain/Inter-Autonomous System routing in the TCP/IP
and OSI Internets is outside the scope of this document. The whole
family of IDRP related documents and their functions are listed in
[2].
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
1. Overview
IDRP ([1]) is defined as the protocol for exchange of
Inter-Domain routing information between routers to support
forwarding of ISO 8473 (Connectionless Network Layer Protocol
(CLNP))[3] PDUs.
The network reachability information exchanged via IDRP provides
sufficient information to detect routing loops and enforce routing
decisions based on performance preference and policy constraints as
outlined in RFC 1104 [10]. In particular, IDRP exchanges routing
information containing full domain-level paths and enforces routing
policies based on configuration information.
As the Internet has evolved and grown over in recent years, it has
Expiration Date September 1993 [Page 1]
- 2 -
become painfully evident that it is soon to face several serious
scaling problems. These include:
- Exhaustion of the class-B network address space. One
fundamental cause of this problem is the lack of a network
class of a size which is appropriate for mid-sized
organization; class-C, with a maximum of 254 host addresses, is
too small while class-B, which allows up to 65534 addresses, is
too large to be densely populated.
- Growth of routing tables in Internet routers are beyond the
ability of current software (and people) to effectively manage.
- Eventual exhaustion of the 32-bit IP address space.
It has become clear that the first two of these problems are likely
to become critical within the next one to three years. Classless
inter-domain routing (CIDR) [8], [11] attempts to deal with these
problems by proposing a mechanism to slow the growth of the routing
table and the need for allocating new IP network numbers. It does not
attempt to solve the third problem, which is of a more long-term
nature, but instead endeavors to ease enough of the short to mid-term
difficulties to allow the Internet to continue to function
efficiently while progress is made on a longer- term solution.
IDRP may be viewed as an extension of BGP-4 [12] that provides (among
other things) much better scaling with respect to support for routing
information aggregation and reduction based on CIDR, as well as
stronger capabilities for policy based routeing (e.g. ability to
impose control over transit traffic).
This document contains the appropriate adaptation of the IDRP
protocol definition that enables it to be used as a protocol for the
exchange of inter-autonomous system information among routers to
support the forwarding of IP packets across multiple autonomous
systems.
The adaptation is defined is such a way that a Dual IDRP will be
able to fully interoperate with IDRP for IP.
2. Terminology
This document assumes that the reader is familiar with the
following documents:
- IP protocol specification (RFC 791)[6], and
Expiration Date September 1993 [Page 2]
- 3 -
- IDRP specification (IS 10747).
A few definitions are in order to aid the reader:
BIS - a Boundary Intermediate System (or border router)
BISPDU - an IDRP message exchanged between a pair of BISs
FIB - Forwarding Information Base (IP forwarding table)
IS - Intermediate System (router)
NET - Network Entity Title - an ISO network address for a
router
NLRI - Network Layer Reachability Information (set of reachable
destinations)
NPDU - an IP packet
PDU - a packet
SNPA - subnetwork point of attachment (MAC address)
3. Assumptions
The IDRP for IP protocol assumes that within a single connected
internet network addresses are unique. The IDRP for IP protocol
cannot be guaranteed to work in an environment where network
addresses within a single connected internet are not unique.
All of the discussions in this document are based on the assumption
that the Internet is a collection of arbitrarily connected Autonomous
Systems. That is, the Internet will be modeled as a general graph
whose nodes are AS's and whose edges are connections between pairs of
AS's.
The classic definition of an Autonomous System is a set of routers
under a single technical administration, using an interior gateway
protocol and common metrics to route packets within the AS and using
an exterior gateway protocol to route packets to other AS's. Since
this classic definition was developed, it has become common for a
single AS to use several interior gateway protocols and sometimes
several sets of metrics within an AS. The use of the term Autonomous
System here stresses the fact that, even when multiple IGPs and
metrics are used, the administration of an AS appears to other AS's
to have a single coherent interior routing plan and presents a
consistent picture of which networks are reachable through it.
Expiration Date September 1993 [Page 3]
- 4 -
AS's are assumed to be administered by a single administrative
entity, at least for the purposes of representation of routing
information to systems outside of the AS.
4. The Adaptation Layer
The Inter-Domain Routing Protocol (IDRP) or, more formally,
"The Protocol for the Exchange of Inter-Domain Routeing
information among Intermediate Systems to support Forwarding
of ISO 8473 PDUs (IDRP)"
is the inter-domain routing protocol defined to support the
forwarding of Connectionless Network Layer Protocol (CLNP) [ISO
8473] packets that traverse multiple routing domains.
While this protocol was developed within ISO, it make few, if any,
ISO-specific assumptions. In particular, it does not require
participating domains to support any specific ISO Intra-Domain
protocol, such as IS-IS (ISO IS 10589)[4], nor does it require
participating routers to run ES-IS (ISO 9542) [5]. The only
requirements imposed by the protocol on the participating routers is
that the protocol information can be exchanged between them over
a connectionless network layer, which in the case of OSI is CLNP, and
that the network layer connectivity between routers within a
single routing domain should be provided by means outside of IDRP
(e.g., via some intra-domain routing protocol). IDRP does not
place any restrictions on the structure of reachability information,
as long it can be expressed as an arbitrary set of variable length
address prefixes.
Since IP can provide connectionless service between routers, and
since reachable IP destinations can be expressed as IP address
prefixes, IDRP can be easily adapted to be an Inter-Autonomous
system routing protocol which can be used in the pure TCP/IP
Internet.
While conceptually it is possible to define a mapping between the
security field of an IP header and IDRP NPDU-derived Distinguishing
Attributes, this mapping is outside the scope of this document. In
addition, address-specific QoSs (Source Specific QoS and Destination
Specific QoS) have no counterparts in IP. Therefore, the use of the
following IDRP Distinguishing Attributes for IP packets will not be
defined in this document:
- Priority
Expiration Date September 1993 [Page 4]
- 5 -
- Locally Defined QOS
- Security
Mapping between the following IDRP Distinguishing Attributes:
- Transit Delay
- Residual Error
- Expense
and the IP Type of Service (TOS) parameters is defined in Section
5.2.3 of this document.
Note that an implementation that does not support any of the
NPDU-derived Distinguishing Attributes can fully interoperate
with an implementation that does support them. Therefore, an IDRP for
IP implementation that will support routing sensitive to the
parameters present in the TOS field of the IP header will be
compatible with the implementation that does not provide such
support.
5. Implementor's Guide for IP specific functions.
In order to implement IDRP for IP, only a subset of the features of
the IDRP protocol must be implemented.
5.1 Features in IDRP which shall not be implemented
The functions of the IDRP protocol which shall not be implemented
for IDRP for IP are those functions which deal with the following
(all references are with respect to the IDRP document [1]):
- Locally Defined QOS according to section 7.11.11
- Security according to section 7.11.14
- Priority according to section 7.11.16
- Forwarding CLNP packets according to section 8
- The interface to CLNP according to section 9
- support of the Network Management information described in the
IDRP GDMO according to section 11
Expiration Date September 1993 [Page 5]
- 6 -
Therefore, with IDRP for IP the following items dealing with CLNP in
the IDRP conformance clause (section 12.1 of [1]) shall not be
implemented:
- clause (d): Locally Defined QOS, Security, Priority
- clause (r)
- clause (s)
- clause (t)
5.1.1 PICS Table Information
The PICS (Protocol Implementation Conformance Statement) provides a
convenient and concise mechanism to define which function need and
need not be implemented for IDRP for IP. All references in this
section are with respect to [1]. All items with PICS Status as
Optional need not be implemented in IDRP for IP. Specifically, IDRP
for IP does not require (and, indeed, does not need) support for the
following items:
A.4.3 Table 9:
MGT
A.4.8 (Table 14):
PSRCRT, DATTS, MATCH
A.4.11 (Table 17):
LQOSG, SECG, PRTY
A.4.11 (Table 18):
LQOSP, SECP, PRTYP
A.4.11 (Table 19):
LQOSR, SECR, PRTYR
Implementation of all other items with Optional Status not listed in
the previous paragraph is optional.
5.2 Features in IDRP which shall be implemented
An implementation of IDRP for IP shall contain all mandatory
features of IDRP, except those mentioned in Section 5.1 of this
document. In addition, a BIS for IDRP for IP shall implement:
Expiration Date September 1993 [Page 6]
- 7 -
- an interface to the IP protocol described in section 5.2.1 of
this document
- the ability to identify and extract IP reachability and IP
forwarding information as described in section 5.2.2 of this
document
- IP packet forwarding functions described in section 5.2.6 of
this document
- domain configuration information listed in section 5.2.5 of
this document
- the advertisement of IP address information in NLRI as
described in section 5.3 of this document
5.2.1 Exchanging IDRP information between IP-only routers.
IDRP assumes pair-wise communication between participating BISs.
IDRP information is carried between a pair of BISs in the form of
BISPDUs. In the case of IDRP for IP, these BISPDUs are carried in
the data field of IP packets of protocol type TBD.
5.2.2 Identifying IP reachability and IP forwarding information
NLRI passed by the UPDATE PDU has an indication of protocol type. An
implementation of IDRP for IP shall have the following values in the
NLRI field:
Proto_Type: 1 (ISO/IEC TR 9577 IPI/SPI)
Proto_Length: 1
Protocol: hexadecimal 'CC'
Addr_Length: variable (the value shall be between 4 and 32)
Addr_Info: IP address prefixes, encoded in binary
An implementation of IDRP for IP shall ignore any NLRI indicating a
different protocol type.
The NEXT_HOP attribute in the UPDATE PDU also has a Type field which
indicates the protocol family for the address of the NEXT_HOP. An
implementation of IDRP for IP shall have the following values in the
NEXT_HOP field:
Expiration Date September 1993 [Page 7]
- 8 -
Proto_Type: 1 (ISO/IEC TR 9577 IPI/SPI)
Proto_Length: 1
Protocol: hexadecimal 'CC'
Length of NET: 4
NET of Next Hop: an IP address, encoded in binary
SNPA information: as appropriate for the subnetwork type in use
An implementation of IDRP for IP shall ignore any NEXT_HOP
information indicating a different protocol type.
5.2.3 Mapping between IP Type Of Service parameters and IDRP
Distinguishing Attributes.
IP defines four distinct Type of Service (TOS) Parameters (see [13]):
- minimize delay
- maximize throughput
- maximize reliability
- minimize monetary cost
An IP packet can carry at most one of the above TOSs. Therefore, a
RIB in IDRP for IP can have at most one distinguishing attribute.
IDRP for IP supports the following distinguishing attributes:
- Transit Delay
- Residual Error
- Expense
A conformant implementation is required to recognize these attributes
when received from an adjacent BIS.
An IP-derived distinguishing attribute is defined as the TOS
parameter extracted from an IP packet that needs to be forwarded by a
BIS.
If the value of the MBZ bit (bit 7) of the Type of Service octet in
the IP header is 1, or if the IP header carries Maximize Throughput
TOS, then the IP-derived distinguishing attribute is mapped into the
Expiration Date September 1993 [Page 8]
- 9 -
"default" RIB-Att (RIB with no distinguishing attributes). Otherwise,
the mapping between the IP-derived distinguishing attribute and a
RIB-Att is defined as follows:
IP TOS IDRP Distinguishing Attribute
------ -----------------------------
minimize delay Transit Delay
maximize reliability Residual Error
minimize monetary cost Expense
5.2.4 Confederations of Autonomous Systems.
IDRP supports the ability to group Routing Domains into a Routing
Domain Confederation. Likewise, IDRP for IP supports the ability to
group a collection of autonomous systems into a Confederation of
autonomous systems. With respect to the IDRP document in the context
of IDRP for IP, the terms "Routing Domain Confederation" and
"Confederation of autonomous systems" should be treated as
synonymous.
5.2.5 Domain Configuration Information
Correct Operation of IDRP described in [1] assumes that a minimum
amount of information is available to both the inter-domain and
intra-domain routing protocols. This information is static in
nature, and is not expected to change frequently. This document
assumes that this information is supplied via IDRP MIB ([7]). While
the following in phrased in terms of MIB, this document allows
alternative mechanisms (e.g. configuration files) as well.
The information required by a BIS that implements the IDRP for IP
protocol is:
a) Location and identity of adjacent Intra-Domain ISs (routers)
The MIB table INTRA-IS lists the IP addresses of the routers
to which the local BIS may deliver an inbound NPDU whose
destination lies within the BIS's routing domain. These
routers listed in the INTRA-IS table support the intra-domain
routing protocol of this autonomous system, and share at
least one common subnet with the BIS.
Expiration Date September 1993 [Page 9]
- 10 -
In particular, if the local BIS participates in both the
inter-domain routing protocol (IDRP) and the intra-domain
routing protocol, then the IP address of the local BIS will be
listed in the INTRA-IS table.
b) Location and identity of BISs in the BIS's domain
This information permits a BIS to identify all other BISs
located within its routing domain. This information is
contained in the MIB table INTERNAL-BIS, which contains a
set of IP addresses which identify the BISs in the domain.
c) Location and identity of BISs in adjacent domains:
Each BIS needs information to identify the IP address of
each BIS located in an adjacent RD and reachable via a
single subnetwork hop. This information is contained in the
IDRP MIB table EXTERNAL-BIS-NEIGHBORS, which is a table of IP
addresses.
d) IP network address information for all systems in the routing
domain
This information is used by the BIS to construct its
network layer reachability information. This information is
contained in the MIB table INTERNAL-SYSTEMS. The IP
network address information shall be expressed in terms of IP
address prefixes. A single prefix can be used to describe:
- host address,
- subnetwork number
- network number
- a collection of contiguous network numbers
e) LOCAL RDI
This information is contained in managed object LOCAL-RDI; it
is the RDI of the routing domain in which the BIS is
located. As specified in section 7 of this document, the RDI
for an IDRP for IP routing domain has an NSAP Address format.
This NSAP Address format is built out of a fixed "header" and
the autonomous system number of this autonomous system (routing
domain).
f) RIB-AttSet
The RIB-AttSet contains information about the QoS functions
Expiration Date September 1993 [Page 10]
- 11 -
a BIS will support. As described in section 4, this can be
none, any, or all of the Transit Delay, Residual Error, and
Expense distinguishing attributes.
g) RDC-Config:
This information identifies all the routing
domain confederations (RDCs) to which the RD of the local BIS
belongs, and it describes the nesting relationships that
are in force between them. It is contained in the MIB table
RDC-Config.
Each RDC is identified by an RDI which has the format
described in section 7 of this document.
Note that since a domain is not required to belong to a
confederation this information is optional and needs to be
present only at BISs of the domains that are part of one or
more of RDCs.
h) Local IP addresses
The LOCAL IP MIB table contains a list of IP addresses assigned
to the interfaces of a BIS. This information is used to
determine what interface should be used to forward outgoing
NPDUs.
5.2.6 Forwarding of IP packets
This section is intended to define the same function for IP
packets as is defined for CLNP packets in the "Forwarding Process for
CLNS" (Section 8 in [1]).
It is assumed that a BIS is capable of distinguishing between a FIB
constructed by means of an intra-autonomous system routing protocol
and a FIB constructed by means of IDRP.
After a BIS determines the packet's destination IP address, the BIS
shall proceed as follows:
a) If the destination address depicts a system located within the
autonomous system of the receiving BIS, then the BIS shall forward
the IP packet to any of the ISs listed in the managed object
INTRA-IS. That is, any further forwarding of the IP packet is the
responsibility of the intra-autonomous system routing protocol;
otherwise,
b) the destination system is located in a different autonomous
Expiration Date September 1993 [Page 11]
- 12 -
system, and the local BIS shall perform the following actions:
It shall determine the IP-Derived Distinguishing Attribute,
according to clause 5.2.3. It shall next apply the procedures
of clause 5.2.3 to determine if the IP-Derived Distinguishing
Attribute matches any of the RIB-Atts of the information
base(s) supported by the local BIS. If such a match is found,
then the FIB with the matched RIB-Atts is used for forwarding.
If the procedures of clause 5.2.3 identify a non-default IP-
Derived Distinguishing Attribute, but the local BIS does not
maintain a FIB with the matching RIB-Atts, or the local BIS
maintains a FIB with the matching RIB-Atts but this FIB does
not have a route to the destination, then the local system sets
the MBZ bit (the 7th bit) of the Type Of Service field in the
IP packet to 1 and uses FIB with no distinguishing attributes.
The incoming IP packet shall be forwarded based on the FIB
entry that has the longest IP address prefix that matches the
destination of the incoming IP packet, as follows:
1) If the entry in the inter-domain FIB that corresponds
to the destination address of an incoming IP packet
contains a NEXT_HOP that identifies an interface of a BIS
such that the interface is attached to a subnet shared with
the local BIS, then the IP packet shall be forwarded
directly to the BIS indicated in the NEXT_HOP entry over
that interface; otherwise,
2) if the entry in the inter-domain FIB that corresponds to
the destination address of the incoming IP packet contains
a NEXT_HOP entry that identifies an interface of a BIS such
that the interface is not attached to any of the subnets
attached to the local BIS, then the local BIS has the
following options:
i) Encapsulate the IP packet
The local BIS may encapsulate the IP packet, using its
own IP address as the source address and the IP
address of the next-hop BIS contained in the NEXT_HOP
entry as the destination address. Since IP doesn't
have a standard encapsulation protocol, use of this
option should be discouraged.
ii) Use paths calculated by the intra-autonomous system
routing protocols
Expiration Date September 1993 [Page 12]
- 13 -
The local BIS may query the FIB constructed by the
intra-autonomous system routing protocols to ascertain
if that FIB contains a route to the destination
system. If that is the case, and if the path
constructed by the intra-autonomous system routing
protocols delivers the IP packet to the appropriate
next-hop BIS, then the IP packet may be forwarded
using the FIB constructed by the intra-autonomous
system routing protocols.
ITEM Questions/Features Refer. Status Support
----------------------------------------------------------------
IP_EXTFWD Does the BIS correctly forward 5.3 M Yes___
IP packets with destinations
outside its routing domain?
IP_INTFWD Does the BIS correctly forward 5.3 M Yes___
IP packets with destinations
inside its routing domain?
---------------------------------------------------------------
Table 1: PICS Proforma for IDRP: IP packet forwarding
The "ITEM" column describes the feature in the IP forwarding
function that the IDRP implementation is to provide. The
"Question/Feature" section seeks to describe the feature. The
Reference is the section in this document that describes this
feature. The status gives an indication of "M" - Mandatory
feature for an IDRP implementation or "O" - optional feature. The
"Support" column is a column for the implementor to check whether
this feature is available in a particular
implementation.)
5.3 Advertising NLRI information for IP addresses
The NLRI field in an UPDATE PDU contains IP address information
Expiration Date September 1993 [Page 13]
- 14 -
about systems that reside within a given routing domain or whose IP
address space is under the control of the administrator of the
routing domain. It should not be used to convey information about
the operational status of these systems. The information in the
NLRI field is intended to convey static administrative information
rather than dynamic transient information; for example, it is not
necessary to report that a given system has changed from offline to
online.
End systems (hosts) and Intermediate systems (routers) within a RD
using IDRP may use any IP address that is valid within the IP
context. Within the NLRI, the address information for a set of IP
addresses may be represented by an IP prefix. An IP prefix is the
sequence of bits in a 4 byte IP address which are common between
a set of IP addresses.
For example, the addresses 192.5.0.0 through 192.5.255.255 have the
first 16 bits of the address information in common. These 16 bits
of the IP address may be called an IP prefix which represents
the set of IP addresses 192.5.0.0 through 192.5.255.255.
An IP prefix must contain a contiguous set of bits starting at the
most significant bit, but the bits may cover any part of the 4 byte
IP address. The following guidelines for inclusion of IP address
prefixes in the NLRI field of the UPDATE PDUs originated within a
routing domain will provide efficient use of this protocol:
a) Only IP prefixes representing IP addresses that are within the
control of the Administrator of a given routing domain may be
reported in the NLRI field for a RD. These IP prefixes can
represent IP addresses for systems which are:
- online,
- offline, or
- allocated to the network, but not yet allocated to a machine.
b) IP prefixes representing IP addresses outside of the RD
administrator's control shall not be included in the NLRI.
c) For efficient use of the protocol, the WITHDRAW ROUTES field
should not be used to report the NLRI of systems that are offline.
This field should be used only to advertise IP prefixes for IP
addresses that are no longer under the control of the
administrator of the local routing domain, regardless of
whether the systems are online or offline.
A conformant implementation is required to have the ability to
Expiration Date September 1993 [Page 14]
- 15 -
specify when an aggregated route may be generated out of partial
routing information. A BIS at the border of an autonomous system (or
group of autonomous systems) must be able to generate an aggregated
route for a whole set of NLRIs over which is has administrative
control, even when not all of them are reachable at the same time.
6 Determining the forwarding address (Next Hop)
NEXT_HOP information associated with a particular route shall be
derived from the NEXT_HOP attribute in the UPDATE BISPDU that carries
the route. If that attribute is not present, it shall be derived from
the source IP address of the IP packet that carries the UPDATE BISPDU
containing the route.
7 Routing Domain Identifiers used for both IP and OSI
Routing Domain Identifiers (RDIs) are identifiers used in BISPDUs
to uniquely identify individual routing domains and routing domain
confederations.
For ease of administration, the RDI is taken out of the NSAP
address space. However, the RDI is just a number which identifies
the routing domain, and need not bear any relationship to any
reachable addresses within the domain.
For ease of interworking with other IP inter-autonomous system
routing protocols, The RDI used for an autonomous system running IDRP
for IP should be derived from an appropriately assigned Autonomous
System Number as follows:
47:00:05:c0:01:aa:aa
Where 47:00:05:c0:01 is a unique prefix assigned by a valid
addressing authority (NIST), and aa:aa is the autonomous system
number.
This encoding of the RDI contains a "fixed header" (the
47:00:05:c0:01 sequence) plus the AS value.
(Note: While AS values are currently 2 octets long, IDRP allows
Routing Domain Identifiers to be of arbitrary length. Thus, if the
space of AS numbers is expanded to be greater than two octets, this
may be accommodated by simply lengthening the above encoding--the AS
Expiration Date September 1993 [Page 15]
- 16 -
number following the fixed header is considered to be right
justified, and its size can be unambiguously determined from the RDI
length.)
8 Deployment Guidelines for IDRP for IP
The correct and efficient operation of the IDRP protocol requires
that certain guidelines are used for deployment with ISO routing
Domains. Some equivalent deployment guidelines for IDRP for IP are
required within Autonomous Systems. These guidelines represent only
the required deployment guidelines, and not details on the usage of
IDRP for IP in the Internet.
8.1 Minimum configuration of an Autonomous System
An autonomous system using IDRP for IP must as a minimum contain:
- one BIS, and
- one BIS capable of delivering NPDUs to the intra-domain routing
function if the AS contains hosts.
8.2 Multiple IDRP sessions between the same pair of routers
An IP router may have multiple IP addresses, one for each interface.
In contrast, an OSI Intermediate System has only one Network Entity
Title (network address). An OSI BIS thus may not have multiple IDRP
sessions with another BIS, since the NET is unique and there is no
mechanism for multiplexing sessions. However, an IP router may
potentially have multiple IDRP sessions with another router, since
each BIS may have multiple IP addresses, and one BIS may not be able
to ascertain that those addresses correspond to the same BIS.
Multiple IDRP sessions between IP BISs may not be efficient, but they
are not illegal, nor do they impact the robustness of the IDRP for IP
protocol; they will simply appear as multiple paths to the same
neighboring AS. One possible way of avoiding multiple parallel IDRP
sessions between a pair of BISs within a single autonomous system is
to bind all source addresses of outgoing BISPDUs to the IP address
of a particular interface of the BIS. Likewise, for a pair of BISs
located in adjacent autonomous systems, binding the source addresses
to a single address of an interface attached to a common subnetwork
allows for the elimination of multiple parallel sessions.
Expiration Date September 1993 [Page 16]
- 17 -
9 Interaction with other exterior routing protocols
The guidelines suggested in this section are consistent with the
guidelines presented in [9].
Interaction with other exterior protocols assumes that a BIS, in
addition to IDRP for IP, supports one or more of the following
protocols: EGP2, BGP-3, BGP-4. Thus, a BIS may be an EGP2 or BGP-3 or
BGP-4 speaker.
The interaction between IDRP for IP and other exterior protocols has
two aspects:
- how a route received via EGP2/BGP-3/BGP-4 gets injected into
IDRP for IP
- how a route received via IDRP for IP gets injected into
EGP2/BGP-3/BGP-4
In all cases care must be taken when injecting an IDRP route that
contains DIST_LIST_INCL or DIST_LIST_EXCL attributes. Since none of
the EGP2/BGP-3/BGP-4 has support for these attributes, it is assumed
that the restrictions imposed via DIST_LIST_INCL or DIST_LIST_EXCL
will be imposed by some other means.
It is strongly recommended that the exchange of routing information
via EGP2/BGP-3/BGP-4 between a BIS participating in IDRP for IP and a
pure EGP2/BGP-3/BGP-4 speaker occurs only at the domain (autonomous
system) boundaries.
9.1 Exchanging information with EGP2
This document suggests the following guidelines for exchanging
routing information between IDRP for IP and EGP2.
The routing information (route) received by EGP2 can be injected into
IDRP by constructing an IDRP route with EXT_INFO path attribute. The
autonomous system number of the EGP2 speaker (that advertized a
route) shall be used as the first RDI in the RD_PATH attribute of the
constructed IDRP route.
The routing information received via IDRP for IP can be injected into
EGP2 as well. In this case, however, one needs to be aware of the
potential information explosion when a given IP prefix received from
IDRP denotes a set of consecutive A/B/C class networks. Injection of
IDRP received NLRI that denotes IP subnets requires the BIS to inject
the corresponding network into EGP2. The local system shall provide
mechanisms to control the exchange of reachability information
between EGP2 and IDRP for IP. Specifically, a conformant
Expiration Date September 1993 [Page 17]
- 18 -
implementation is required to support all of the following options
when injecting IDRP received reachability information into EGP2:
- inject default only (0.0.0.0); no export of any other NLRI
- allow controlled deaggregation, but only of specific routes;
allow export of non-aggregated NLRI
9.2 Exchanging information with BGP-3
This document suggests the following guidelines for exchanging
routing information between IDRP for IP and BGP-3.
A BIS may inject the information received by IDRP for IP into BGP-3
as follows. If an RD_PATH attribute of an IDRP route carries RD_SET
path segments, then the AS_PATH attribute of the BGP-3 route shall be
constructed by treating the RD_SET segments as RD_SEQUENCE segments,
with the resulting AS_PATH being a single AS_SEQUENCE. While this
procedure loses set/sequence information, it doesn't affect
protection for routing loops suppression, but may affect policies, if
the policies are based on the content or ordering of the AS_PATH
attribute. If an IDRP route carries ENTRY_SEQ or ENTRY_SET path
segments, then before passing this route to BGP the BIS shall assume
that the route exited all the confederations denoted in ENTRY_SET or
ENTRY_SEQ and update the RD_PATH of the route accordingly. If an
IDRP route carries EXT_INFO path attribute then the corresponding
BGP-3 route shall have value of its ORIGIN attribute set to
INCOMPLETE.
When injecting routes received via BGP-3 into IDRP for IP the AS_PATH
attribute is mapped into the RD_PATH attribute of the type RD_SEQ. If
the BGP-3 route has the value of its ORIGIN attribute set to
anything, but IGP, the corresponding IDRP route shall have EXT_INFO
path attribute.
Observe that the mapping between RD_PATH in IDRP and AS_PATH in BGP-3
is possible only when there is one-to-one mapping between the space
of autonomous system numbers and the space used to assign domain
identifiers for domains running IDRP for IP.
While injecting NLRI derived from IDRP routes into BGP-3, one needs
to be aware of the potential information explosion when a given IP
prefix denotes a set of consecutive A/B/C class networks. Injection
of IDRP derived NLRI that denotes IP subnets requires the BIS to
inject the corresponding network into BGP-3. The local system shall
provide mechanisms to control the exchange of routing information
between BGP-3 and IDRP for IP. Specifically, a conformant
implementation is required to support all of the following options
when injecting IDRP received routing information into BGP-3:
Expiration Date September 1993 [Page 18]
- 19 -
- inject default only (0.0.0.0), no export of any other NLRI
- allow controlled deaggregation, but only of specific routes;
allow export of non-aggregated NLRI
- allow export of only non-aggregated NLRI
9.3 Exchanging information with BGP-4
This document suggests the following guidelines for exchanging
routing information between IDRP for IP and BGP-4.
A BIS may inject a route received via IDRP for IP into BGP-4 as
follows. The RD_PATH attribute is directly translated into the
AS_PATH attribute with RD_SET being mapped into AS_SET, and RD_SEQ
into AS_SEQUENCE. If the RD_PATH attribute of a route contains
ENTRY_SEQ or ENTRY_SET path segments, then prior to injecting the
route into BGP-4 the BIS shall assume that all the confederations
denoted in ENTRY_SEQ or ENTRY_SET are to be exited and process the
RD_PATH accordingly.
If an IDRP route has EXT_INFO path attribute, then the corresponding
BGP-4 route shall have the value of its ORIGIN attribute set to
INCOMPLETE.
When injecting a route received via BGP-4 into IDRP for IP the
AS_PATH attribute of the route is directly translated into the
RD_PATH attribute (with AS_SET being mapped into RD_SET and
AS_SEQUENCE being mapped into RD_SEQ). If an IDRP route carries
EXT_INFO path attribute then the corresponding BGP-4 route shall have
value of its ORIGIN attribute set to INCOMPLETE.
Observe that the mapping between RD_PATH in IDRP and AS_PATH in BGP-4
is possible only when there is one-to-one mapping between the space
of autonomous system numbers and the space used to assign domain
identifiers for domains running IDRP for IP.
If a BGP-4 route that carries the ATOMIC_AGGREGATE path attribute is
to be exported into IDRP for IP then the corresponding IDRP route
shall have EXT_INFO attribute attached to it.
10. Required set of supported routing policies.
Policies are provided to IDRP in the form of configuration
information. This information is not directly encoded in the
protocol. Therefore, IDRP can provide support for very complex
routing policies (an example of such policy is presented in Annex K
of [1]). However, it is not required that all IDRP implementations
support such policies.
Expiration Date September 1993 [Page 19]
- 20 -
We are not attempting to standardize the routing policies that must
be supported in every IDRP implementation; we strongly encourage all
implementors to support the following set of routing policies:
1. IDRP implementations should allow an AS to control
announcements of IDRP-learned routes to adjacent AS's.
Implementations should also support such control with at least
the granularity of a single network. Implementations should
also support such control with the granularity of an autonomous
system, where the autonomous system may be either the
autonomous system that originated the route, or the autonomous
system that advertised the route to the local system (adjacent
autonomous system). Care must be taken when a BIS selects a
new route that can't be announced to a particular external
peer, while the previously selected route was announced to that
peer. Specifically, the local system must explicitly indicate
to the peer that the previous route is now infeasible.
2. IDRP implementations should allow an AS to prefer a particular
path to a destination (when more than one path is available).
This function may be implemented by allowing system
administrators to assign "weights" to AS's, and by having the
route selection process select a route with the lowest "weight"
(where "weight" of a route is defined as a sum of "weights" of
all AS's in the RD_PATH path attribute associated with that
route).
3. IDRP implementations should allow an AS to ignore routes with
certain AS's in the RD_PATH path attribute. Such function can
be implemented by using the technique outlined in [10], and by
assigning "infinity" as "weights" for such AS's. The route
selection process must ignore routes that have "weight" equal
to "infinity".
11 Security Considerations
Security issues are not discussed in this document.
12. Acknowledgements
A large set of thanks to Dave Katz(cisco) who helped edit the
document. I would also like to express my thanks to Scott Brim
(Cornell University) for his review and constructive comments.
The author would like to acknowledge contributions made by authors of
[9], Yakov Rekhter and Phill Gross. Certain sections of this
Expiration Date September 1993 [Page 20]
- 21 -
document are taken (sometimes almost verbatim) from their document.
13. References
[1] ISO/IEC IS 10747 - Information Processing Systems -
Telecommunications and Information Exchange between Systems -
Protocol for Exchange of Inter-domain Routeing Information among
Intermediate Systems to Support Forwarding of ISO 8473 PDUs, 1993.
[2] RFC xxx - (Sue Hares) IDRP Document Family Tree
[3] ISO 8473 - Information Processing Systems - Data
Communications - Protocol for Providing the Connectionless-mode
Network Service, 1988.
[4] ISO/IEC 10589 - Information Processing Systems -
Telecommunications and Information Exchange between systems -
Intermediate System to Intermediate System Intra-Domain routeing
information exchange protocol for use in conjunction with the
Protocol for providing the Connectionless-mode Network Service (ISO
8473), 1992.
[5] ISO 9542 - Information Processing Systems -
Telecommunications and information exchange between systems - End
system to Intermediate system routeing exchange protocol for use in
conjunction with the Protocol for providing the connectionless-mode
network service (ISO 8473)
[6] RFC 791 (Jon Postel, editor) - Internet Protocol - DARPA
Internet Program Protocol Specification (September 1981)
[7] RFC xxx (Susan Hares) - IDRP MIB
[8] Fuller, V., Li, T., Yu, J, and Varadhan, K., "Supernetting: an
Address Assignment and Aggregation Strategy", Internet Draft,
February 1993
[9] Rekhter, Y., Gross, P., "Application of the Border Gateway
Protocol in the Internet", Internet Draft September 1992
[10] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
Merit/NSFNET, June 1989.
[11] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation
with CIDR", Internet Draft February 1993
[12] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4),
Internet Draft, cisco Systems, T.J. Watson Research Center, IBM
Corp., September 1992.
Expiration Date September 1993 [Page 21]
- 22 -
[13] Almquist, P., "Type of Service Routing in the Internet Protocol
Suite", RFC 1248, July 1992.
Expiration Date September 1993 [Page 22]